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Introduction and Background: Planetary geo- 

logic mapping has become complex in terms of merg- 
ing and co-registering a variety of different datasets for 
analysis and mapping. But it has also become more 
convenient when it comes to conducting actual (geo- 
scientific) mapping with the help of desktop Geo- 
graphic Information Systems (GIS). The complexity 
and variety of data, however, are major issues that 
need to be taken care of in order to provide mappers 
with a consistent and easy-to-use mapping basis. Fur- 
thermore, a high degree of functionality and interop- 
erability of various commercial and open-source GIS 
and remote sensing applications allow mappers to or- 
ganize map data, map components and attribute data in 
a more sophisticated and intuitional way when com- 
pared to workflows 15 years ago. 

Integration of mapping results of different groups 
becomes an awkward task as each mapper follows 
his/her own style, especially if mapping conduct is not 
coordinated and organized programmatically. Prob- 
lems of data homogenization start with various inter- 
pretations and implementations of planetary map pro- 
jections and reference systems which form the core 
component of any mapping and analysis work. If the 
data basis is inconsistent, mapping results in terms of 
objects’ georeference become hard to integrate. 

Apart from data organization and referencing is- 
sues, which are important on the mapping as well as 
the data-processing side of every project, the organiza- 
tion of planetary geologic map units and attributes, as 
well as their representation within a common GIS en- 
vironment, are key components that need to be taken 
care of in a consistent and persistent way. 

Employing Geodatabases: Today, still very few 
organizations in the field of planetary mapping seem to 
employ object-relational geodatabase management 
systems (GDBMS) although such environments form 
the backbone of any GIS. ESRI’s ArcGIS environment 
allows each user to create a local database stored di- 
rectly as part of the computer’s file system and man- 
aged by ArcGIS without having to set up a server- 
client-based database management sytem (DBMS). A 
file-based geodatabase (FGDB) is transportable (via 
Extensible Markup Language Metadata Interchange 
format; XMI) and can be easily migrated, and its lay- 
out can be modified and adapted to fit specific re- 
quirements. The FGDB layout (model schema) is eas- 
ily transferable to a DBMS if there is a need to migrate 


and set up a larger-scale environment or switch to oth- 
er GIS applications. The reasons to switch to database- 
organization (either file-based or based on a server 
management system) for planetary mapping conduct 
are twofold. The first reason is concerned with data 
homogenization and integration as outlined above. The 
database model provides boundary constraints in terms 
of reference systems and map projection issues which 
control and safeguard the proper use of data (e.g., ras- 
ter or feature datasets form containers with associated 
reference and map projection definitions to control 
individual feature class objects). 

The second reason is concerned with attribute val- 
ues for specific feature class objects (a map unit, a 
contact), feature datasets and relations. Once attributes 
for feature classes and additional relations are defined 
they can be imported and utilized without having to set 
up feature objects manually, thus avoiding inconsis- 
tencies. Secondly, once feature classes and relations 
are defined, they can interact by relationship classes 
and subtype-driven domain assignments which conse- 
quently allow the user to (a) query data in a limited 
(when FGDB-based) or highly sophisticated (when 
DBMS-based) way and (b) select only attribute values 
that are within a given domain and controlled by sub- 
types. This not only prevents erroneous entries but it 
also allows working much more efficiently, even col- 
laboratively if required. Furthermore, a rich set of to- 
pology classes improves the quality and consistency of 
mapping work by, e.g., controlling different feature 
classes covering geologic and/or geomorphologic 
mapping units. 

Key DB-Model Components: We will present the 
current status and key components of DB-model de- 
velopments and focus on tasks dealing with (a) organ- 
izational and (b) geoscientific mapping issues. The 
geoscientific parts are covered by relations dealing 
with stratigraphic issues and surface-material assign- 
ments and relationships in the context of chronostrati- 
graphy and model ages (including concepts on selec- 
tion processes), integration of geologic and geomor- 
phologic mapping units on different object levels and 
the possible organization and representation of carto- 
graphic symbologies beyond proprietary solutions. 
Additionally, we will discuss the implementation (and 
benefit) of topologic constraints and the migratability 
to DBMS and other GIS environments 
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